Tcl_Interp *_i_n_t_e_r_p (in) Interpreter to use for error
reporting.
Tk_Window _t_k_w_i_n (in) Token for window in which color will
be used.
Tk_Uid _n_a_m_e_I_d (in) Textual description of desired color.
XColor *_p_r_e_f_P_t_r (in) Indicates red, green, and blue
intensities of desired color.
XColor *_c_o_l_o_r_P_t_r (in) Pointer to X color information. Must
have been allocated by previous call
to TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrr or TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrrBBBByyyyVVVVaaaalllluuuueeee,
except when passed to TTTTkkkk____NNNNaaaammmmeeeeOOOOffffCCCCoooolllloooorrrr.
Drawable _d_r_a_w_a_b_l_e (in) Drawable in which the result graphics |
context will be used. Must have same |
screen and depth as the window for |
which the color was allocated.
DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
The TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrr and TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrrBBBByyyyVVVVaaaalllluuuueeee procedures locate pixel values
that may be used to render particular colors in the window given by
_t_k_w_i_n. In TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrr the desired color is specified with a Tk_Uid
(_n_a_m_e_I_d), which may have any of the following forms:
_c_o_l_o_r_n_a_m_e Any of the valid textual names for a color defined in
the server's color database file, such as rrrreeeedddd or
PPPPeeeeaaaacccchhhhPPPPuuuuffffffff.
####_R_G_B
####_R_R_G_G_B_B
####_R_R_R_G_G_G_B_B_B
####_R_R_R_R_G_G_G_G_B_B_B_B A numeric specification of the red, green, and blue
intensities to use to display the color. Each _R, _G,
or _B represents a single hexadecimal digit. The four
forms permit colors to be specified with 4-bit, 8-
bit, 12-bit or 16-bit values. When fewer than 16
bits are provided for each color, they represent the
most significant bits of the color. For example,
#3a7 is the same as #3000a0007000.
In TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrrBBBByyyyVVVVaaaalllluuuueeee, the desired color is indicated with the _r_e_d,
_g_r_e_e_n, and _b_l_u_e fields of the structure pointed to by _c_o_l_o_r_P_t_r.
If TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrr or TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrrBBBByyyyVVVVaaaalllluuuueeee is successful in allocating the
desired color, then it returns a pointer to an XColor structure; the
structure indicates the exact intensities of the allocated color (which
may differ slightly from those requested, depending on the limitations of
the screen) and a pixel value that may be used to draw in the color. If |
the colormap for _t_k_w_i_n is full, TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrr and TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrrBBBByyyyVVVVaaaalllluuuueeee will |
use the closest existing color in the colormap. If TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrr |
encounters an error while allocating the color (such as an unknown color |
name) then NULL is returned and an error message is stored in _i_n_t_e_r_p- |
>_r_e_s_u_l_t; TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrrBBBByyyyVVVVaaaalllluuuueeee never returns an error.
TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrr and TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrrBBBByyyyVVVVaaaalllluuuueeee maintain a database of all the colors
currently in use. If the same _n_a_m_e_I_d is requested multiple times from
TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrr (e.g. by different windows), or if the same intensities are
requested multiple times from TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrrBBBByyyyVVVVaaaalllluuuueeee, then existing pixel
values will be re-used. Re-using an existing pixel avoids any
interaction with the X server, which makes the allocation much more
efficient. For this reason, you should generally use TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrr or
TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrrBBBByyyyVVVVaaaalllluuuueeee instead of Xlib procedures like XXXXAAAAllllllllooooccccCCCCoooolllloooorrrr,
XXXXAAAAllllllllooooccccNNNNaaaammmmeeeeddddCCCCoooolllloooorrrr, or XXXXPPPPaaaarrrrsssseeeeCCCCoooolllloooorrrr.
Since different calls to TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrr or TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrrBBBByyyyVVVVaaaalllluuuueeee may return the
same shared pixel value, callers should never change the color of a pixel
returned by the procedures. If you need to change a color value
dynamically, you should use XXXXAAAAllllllllooooccccCCCCoooolllloooorrrrCCCCeeeellllllllssss to allocate the pixel value
for the color.
The procedure TTTTkkkk____NNNNaaaammmmeeeeOOOOffffCCCCoooolllloooorrrr is roughly the inverse of TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrr. If
its _c_o_l_o_r_P_t_r argument was created by TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrr, then the return value
is the _n_a_m_e_I_d string that was passed to TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrr to create the color.
TTTTkkkk____GGGGCCCCFFFFoooorrrrCCCCoooolllloooorrrr returns a graphics context whose FFFFoooorrrreeeeggggrrrroooouuuunnnndddd field is the |
pixel allocated for _c_o_l_o_r_P_t_r and whose other fields all have default |
values. This provides an easy way to do basic drawing with a color. The|
graphics context is cached with the color and will exist only as long as |
_c_o_l_o_r_P_t_r exists; it is freed when the last reference to _c_o_l_o_r_P_t_r is |
freed by calling TTTTkkkk____FFFFrrrreeeeeeeeCCCCoooolllloooorrrr.
When a pixel value returned by TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrr or TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrrBBBByyyyVVVVaaaalllluuuueeee is no
longer needed, TTTTkkkk____FFFFrrrreeeeeeeeCCCCoooolllloooorrrr should be called to release the color. There
should be exactly one call to TTTTkkkk____FFFFrrrreeeeeeeeCCCCoooolllloooorrrr for each call to TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrr
or TTTTkkkk____GGGGeeeettttCCCCoooolllloooorrrrBBBByyyyVVVVaaaalllluuuueeee. When a pixel value is no longer in use anywhere
(i.e. it has been freed as many times as it has been gotten) TTTTkkkk____FFFFrrrreeeeeeeeCCCCoooolllloooorrrr
will release it to the X server and delete it from the database.